전세계 수만 명의 개발자가 수십 년 동안 서비스를 운영하고 있는 구글의 엔지니어는 어떤 모습일지 영감을 얻기 위해 “구글 엔지니어는 이렇게 일한다.” 책을 구매했다. 이 포스팅은 이 책을 요약한 글이다.
Part1 전제
Chapter 1. 소프트웨어 엔지니어링이란?
- 소프트웨어 엔지니어는 언젠간 변경될 가능성에 신경써야 한다.
- 프로그래밍 작업과 엔지니어링 작업(개발 + 수정 + 유지보수)의 차이는 시간이라는 요소가 더해지면서 입체적으로 바뀐다는 점이다.
- 십 년 이상 살아남는 시스템은 거의 모든 의존성이 처음과 달라질 것이다. 소프트웨어 엔지니어링과 프로그래밍을 가르는 핵심은 이 사실을 인식하는 데서 시작한다. 이 차이가 소프트웨어의 지속 가능성의 핵심이다.
- 초기에 소프트웨어 엔지니어링을 “여러 버전의 프로그램을 여러 사람이 참여해 개발하는 것”이라고 정의했다. 협업 자체로 새로운 문제를 유발하지만, 한 명이 개발하는 것보다 가치 있는 시스템을 만들어낼 잠재력 또한 지닌다.
- ‘조직이 성장하고 프로젝트가 확장될수록 소프트웨어 생산 효율도 높아지는가?’ 규모에 따른 소통, 인력 충원 문제는 소프트웨어 엔지니어링 초창기부터 논의되어 온 주제다.
- 주기적으로 여러 선택지 사이의 트레이드오프를 평가 해야 한다. 때로는 불완전한 지표에 기대어 결과에 커다란 영향을 주는 선택을 해야 한다.
- 지속 가능성을 잃지 않으면서 조직, 제품, 개발 워크플로우의 규모를 확장하는 비용을 관리해야 한다. 이런 사실을 주지하고 트레이드오프를 평가해 합리적인 결정을 내려야 한다.
- 때로는 유지보수에 도움되는 변경, 확장성이 떨어지는 정책을 받아들여야 할 때도 있다. 이런 결정은 훗날 다시 검토해야 할 수 있음을 잊지 말아야 하고, 이 결정 때문에 생긴 지연 비용을 정확히 계산해둬야 한다.
- 규모가 커질수록 효과도 커지는 엔지니어링 생태계의 보고서같은 책이라고 생각하라고 한다.
- 구글에서 대부분 프로젝트는 5년 이내에 업그레이드를 했다.
- 수명이 길어질수록 ‘동작한다’와 ‘유지보수 가능하다’의 차이를 더 분명하게 인지해야 한다.
- 하이럼의 법칙 : 최선의 의도, 최고의 엔지니어, 꼼꼼한 코드 리뷰가 뒷받침되더라도 완벽한 구현이라고 단정할 수 없다는 현실을 표현한 말이다. 이미 사용자가 API를 사용하고 있다면 가장 무해할 듯한 변경도 일부 사용자의 소프트웨어를 망가뜨릴 수 있다. 따라서 변경이 얼마나 유용할 지 조사할 때는 이런 충돌 조사를 하는 비용도 고려해야 한다.
- ‘기발한’이 칭찬으로 느껴지면 프로그래밍이라 하고, 질책으로 느껴진다면 소프트웨어 엔지니어링이라고 한다.
- 코드베이스 자체도 확장 가능해야 한다. 빌드 시간, 레포지토리에서 새로 프로젝트를 내려받는 시간 같은 지표는 적극적으로 관리하지 않으면 천천히 악화된다. 마치 ‘끓는 물 속의 개구리’처럼 위험 순간까지 눈치채지 못할 수 있다. 따라서 이런 문제는 조직 차원에서 챙기며 확장 가능성에 신경 써야 안정되게 관리할 수 있다.
- 마이그레이션을 담당하는 전문 그룹을 운영하는 것이 각자에게 부담시키는 방식보다 확장성이 좋았다.
- 지식을 공유하는 것이 조직 성장에 기여하는 바가 크다는 사실을 알았다. 한 명만 질문에 기꺼이 대답해 줄 엔지니어가 있다면 100명이 있는 조직일 때 더 나은 코드를 작성하는 100명의 엔지니어가 탄생한다.
- 인프라(조직 내 사용하는 모든 자원)는 더 자주 변경할수록 변경하기가 오히려 쉬워진다. 코드가 더 견고해지고, 다음 업그레이드를 하기도 더 쉬워진다. 무엇을 업그레이드하든 첫 번째 업그레이드 때 코드베이스 수정량이 가장 많을 것이다. 이런 경험을 통해 전문성, 안정성, 코드베이스의 순응(업그레이드를 겪지 않은 코드가 더 적다), 익숙함(자동화 노력), 정책(CI같은 유용한 시스템 구축)을 얻을 수 있었다.
이전 회사와 지금 회사에서 겪은 2번의 큰 경험으로 얻었던 교훈을 2006년 구글에서는 이미 가지고 있었다.
- 원점 회귀 : 결함 수정 비용은 왼쪽일수록 낮다. 구글에서는 가능한 많은 버그를 왼쪽에서 잡기 위해 다층 방어 전략을 구축하기 위해 노력한다.
- 개념잡기 → 설계 → 구현 → 리뷰 → 테스트 → 커밋 → 카나리 → 배포
- 비용을 평가할 때 조직의 건설성도 포함되어야 한다. 엔지니어들이 스스로 가치를 느끼고 생산적인 일을 하고 있다고 생각하는지가 포함된다. 행복을 느끼고, 일에 집중하고 참여할 수 있게 해주면 10~20% 생산성 향상은 우습게 만들어 낸다.
Part2 문화
Chapter 2. 팀워크 이끌어내기
- 소프트웨어 개발은 ‘팀의 단합된 노력’의 결실이다.
- 엔지니어링팀이 성공하려면 겸손, 존중, 신뢰에 맞게 자신의 행동을 바로 잡아야 한다.
- 버스 지수 : 몇 명의 팀원이 버스에 치어서 일을 할 수 없게 될 때 프로젝트가 망하게 되는지 나타내는 지수
- 혼자 일하는 것은 고되고, 사람들 기대보다 훨씬 느리다는 점을 잊기 쉽다. 페어프로그래밍을 하는 이유가 여깄다.
- 함수를 짜고 테스트를 짜고, 리팩터링을 하는 것이 가장 빠르게 버그를 잡는 길이다.
- 문제를 빨리 찾을수록 고치는 비용이 낮아진다.
- 사례 연구를 통해, 4~8명 정도마다 사무실을 배정했을 때 생산적인 대화가 이루어진다.
- 구글에서는 “지금은 바쁘니 가능한 방해하지 말아달라”의 뜻을 만들어 사용했다고 한다. 모니터 위에 토큰이나 인형 같은 것을 올려놓는 식으로.
- 하지만, 소통의 단절은 좋지 않다. 적절한 균형점을 찾는 것이 중요하고 정답은 없다.
- 위대한 소프트웨어를 만드는 위대한 팀을 만들기 위해서는 ‘세 기둥’을 먼저 배우고 익혀야 한다.
- 겸손 : 당신과 당신의 코드는 우주의 중심이 아니다. 당신은 모든 것을 알지도, 완벽하지도 않다. 겸손한 사람은 배움에 열려있다.
- 존중 : 함께 일하는 동료를 진심으로 생각한다. 친절하게 대하고, 그들의 능력과 성취에 감사해한다.
- 신뢰 : 동료들이 유능하고 올바른 일을 하리라 믿는다. 필요하면 그들에게 스스로 방향을 정하게 한다.
- 건설적인 비판하는 사람은 상대방을 진심으로 생각하고, 상대방 업무가 개선되길 바라야 한다는 것.
- 동료를 존중하는 법을 배우고, 건설적이고 공손하게 비평하는 법을 배워야 한다.
- 반대로 자신도 비평을 잘 수용할 줄 알아야 한다.
- “잘못했다”고 하고 “고치라고 요구”도 해서는 안된다.
- “이 부분의 제어 흐름이 좀 헷갈리네요. 혹시 xyz 코드 패턴을 적용하면 더 명확해질까요? 나중에 관리하기 쉬워질지도 모르겠네요”식으로 상대가 아닌 자신을 겸손하게 낮춰서 대화하는 것이 좋다. 아무것도 요구하지 않고, 동료가 제안을 거부해도 부담을 느끼지 않도록 배려했다. “가치”나 “코딩 기술”이 아니라 코드 자체에 집중하고 있다.
- 구글에서는 ‘실패는 선택이다’라는 좌우명이 있다. ‘가끔씩 실패하지 않는다면 충분히 혁신적이지 않거나 위험을 충분히 감수하지 않은 것이다’라는 믿음으로 통용된다.
- 실패를 ‘배우고 다음 단계로 넘어갈 수 있는 절호의 기회’라고 생각한다.
- 구글 X사업부에서는 “실패”를 보상 제도에 녹였다. 잘못된 아이디어임을 증명할 수 있는 동료가 하나도 없는 경우에 초기 프로토타이핑 단계로 넘어갔다.
- 실패한 근본 원인을 분석해서 문서로 남기는 것이 실수로부터 배우는 ‘핵심’이다. 이를 ‘포스트모템’이라고 한다.
- 포스트모템을 작성할 때 주의할 점 : 사죄, 변명, 지적으로 채워지지 않도록 주의하라.
- 포스트모템을 작성할 때 다음 내용이 담겨야 한다.
- 사건 개요
- 인지 ~ 해결까지 타임라인
- 원인
- 피해 평가
- 즉시 해결한 조치 사항
- 재발 방지 방법
- 교훈